E-fuses for storing security version data

ABSTRACT

Methods and devices that may be utilized in systems to dynamically update a security version parameter used to encrypt secure data are provided. The version may be maintained in persistent storage located on a device implementing the encryption, such as a system on a chip (SOC). The persistent storage does not require battery backing and, thus, the cost and complexity associated with conventional systems utilizing battery backed storage may be reduced.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 10/892,431, filed Jul. 15, 2004, which is hereby incorporatedby reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to data encryption and, moreparticularly, to methods and apparatus for updating parameters used forencryption, such as version control parameters.

2. Description of the Related Art

A system on a chip (SOC) generally includes one or more integratedprocessor cores, some type of embedded memory, such as a cache sharedbetween the processors cores, and peripheral interfaces, such as memorycontrol components and external bus interfaces, on a single chip to forma complete (or nearly complete) system. The use of cache memoryhierarchies is well established to improve a processor performance byreducing and/or eliminating read access requests to external mainmemory.

As part of an enhanced security feature, some SOCs encrypt some portionsof data prior to storing it in external memory. Adding such encryptionto an SOC may add valuable benefits, such as preventing a hacker fromobtaining instructions of a copyrighted program, such as a video game,or data that may be used to determine such instructions through reverseengineering. When the encrypted data is subsequently retrieved fromexternal memory, it must first be decrypted before it can be used by theprocessor cores.

The encryption is typically carried out with the use of one or moreencryption keys generated, in some way, based on a master key. Often themaster key is unique to the device, in an effort to ensure no twodevices perform encryption in the exact same way. In some cases, asecurity version parameter (hereinafter, simply the version) maintainedon the system may be used in combination with the encryption, in aneffort to provide some degree of flexibility regarding how and on whatencryption is performed. A current version may reflect a current stateof privileges a user has, in effect, determining what content the usermay access. As an example, in a gaming system a user may purchase anddownload a new game. As part of the process of installing the new gameon the system, the version may be updated and used to encrypt the gameprogram, with the game, in encrypted form, marked as having beenencrypted using the updated version. Upon loading the game, systemvalidation logic may compare the current version of the system againstthe version used to encrypt the game to verify the system is authorizedto run the game. If the versions match, the game will be decrypted andallowed to run, otherwise it will not.

In conventional systems, master key and version data are often stored inbattery backed registers or external nonvolatile storage, such asbattery-backed non-volatile random access memory (NVRAM). Unfortunately,batteries are expensive and the reliance on batteries introducescomplexity as designers must deal with the possibility of having torestore values in the event battery voltage is lost. Further, storingmaster key and version data in external memory invites attacks byhackers attempting to gain unauthorized access. To combat this, somesystems utilize tamper detection hardware designed to notify the systemin the event unauthorized access is detected, which also increasessystem cost.

Accordingly, what is needed is a mechanism for storing Master Key andversion information that does not require batteries. Preferably, such amechanism would allow Master Key and version information to bemaintained internal to a device, such as an SOC, implementing security.

SUMMARY OF THE INVENTION

The present invention generally provides methods and devices fordynamically updating security version parameters stored in persistentstorage.

One embodiment provides a method of handling secure data in a securesystem, wherein the secure data is passed between a processor and memoryexternal to the processor. The method generally includes maintaining asecurity version parameter in persistent storage on the processor,wherein blocks of secure data are encrypted as a function of thesecurity version parameter and dynamically changing the security versionparameter by modifying the contents of the persistent storage.

Another embodiment provides a method of handling secure data in a securesystem, wherein the secure data is passed between a processor and memoryexternal to the processor. The method generally includes maintaining asecurity version parameter and master key data in persistent storage onthe processor, encrypting a block of secure data, generating anintegrity check value for the block of secure data, wherein at least oneof the encrypting and the generating is performed as a function of thesecurity version parameter, storing the encrypted block of secure datain the external memory, and dynamically changing the security versionparameter by modifying the contents of the persistent storage.

Another embodiment provides a device for encrypting blocks of data to bestored in memory external to the device. The device generally includesfirst persistent storage elements for storing a security versionparameter, second persistent storage elements for storing master keydata, an encryption engine configured to encrypt secure blocks of datato be stored in the external memory, wherein at least one of: theencrypted secure blocks or an integrity check value generated thereforeare affected by the security version parameter, and a mechanism formodifying the first persistent storage elements to update the securityversion parameter without modifying previously modified first persistentstorage elements.

Another embodiment provides a method of handling secure data in a securesystem, wherein the secure data is passed between a processor and memoryexternal to the processor. The method generally includes maintaining asecurity version parameter and master key data in persistent storage onthe processor and storing first and second copies of an encrypted datastructure in external memory, wherein at least one of: the encrypteddata structure or an integrity check value calculated therefor areaffected by the security version parameter. The security versionparameter may be updated without modifying the contents of thepersistent storage. The first copy of the encrypted data structure maybe overwritten with a new encrypted data structure, wherein at least oneof: the encrypted data structure or an integrity check value calculatedtherefor are affected by the updated security version parameter. Thefirst copy of the new encrypted data structure may be read back andvalidated. The persistent storage may be updated to reflect the updatedsecurity version parameter only if the first copy of the new encrypteddata structure is valid.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features, advantages andobjects of the present invention are attained and can be understood indetail, a more particular description of the invention, brieflysummarized above, may be had by reference to the embodiments thereofwhich are illustrated in the appended drawings.

It is to be noted, however, that the appended drawings illustrate onlytypical embodiments of this invention and are therefore not to beconsidered limiting of its scope, for the invention may admit to otherequally effective embodiments.

FIG. 1 illustrates an exemplary system including a CPU, in whichembodiments of the present invention may be utilized.

FIGS. 2A-2B are block diagrams illustrating data flow through the CPU,according to one embodiment of the present invention.

FIGS. 3A and 3B illustrate different configurations of persistentstorage, according to exemplary embodiments of the present invention.

FIG. 4 is a flow diagram of exemplary operations for initializing secureoperations utilizing master key and version data in persistent storageaccording to one embodiment of the present invention.

FIG. 5 is a flow diagram of exemplary operations for secure runtimeoperations utilizing master key and version data in persistent storageaccording to one embodiment of the present invention.

FIG. 6 is a flow diagram of exemplary operations for secure updating ofversion data in persistent storage according to one embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the present invention may be utilized in systems todynamically update a security version parameter used to encrypt and/orvalidate secure data. The version may be maintained in persistentstorage located on a device implementing the encryption, such as asystem on a chip (SOC). The persistent storage does not require batterybacking and, thus, the cost and complexity associated with conventionalsystems utilizing battery backed storage may be reduced. Further, byutilizing persistent storage that does not allow previously writtenstorage elements to be re-written (erased) an additional level ofsecurity may be achieved, by avoiding inadvertent or intentional (e.g.,initiated by a hacker) rollback of versions.

As used herein, the term security metadata generally refers to any typeof data used during any part of the encryption process. For example,security metadata may include such data as encryption keys, versionnumbers, and the like, used to encrypt and/or validate data. As usedherein, the term secure data refers to data that is to be encrypted whenstored external to an encryption-enabled device, such as an SOC, whilethe term non-secure data refers to data that may be stored externally innon-encrypted form. Data that is non-encrypted (whether secure ornon-secure) is referred to herein as plaintext while data that isencrypted is referred to herein as ciphertext. These terms are used forconvenience and do not imply the encrypted or non-encrypted data isactually textual data.

In the following, reference is made to embodiments of the invention. Itshould be understood, however, that the invention is not limited to anyspecific embodiments described herein. Instead, any combination of thefollowing features and elements, whether related to differentembodiments or not, is contemplated to implement and practice theinvention. Furthermore, in various embodiments the invention providesnumerous advantages over the prior art. However, although embodiments ofthe invention may achieve advantages over other possible solutionsand/or over the prior art, whether a particular advantage is achieved bya given embodiment is not limiting of the invention. Thus, the followingaspects, features, embodiments and advantages are merely illustrativeand, unless explicitly present, are not considered elements orlimitations of the appended claims.

An Exemplary System

Referring now to FIG. 1, an exemplary computer system 100 including acentral processing unit (CPU) 110 is illustrated, in which embodimentsof the present invention may be utilized. As illustrated, the CPU 110may include one or more processor cores 112, which may each include anynumber of different type functional units including, but not limited toarithmetic logic units (ALUs), floating point units (FPUs), and singleinstruction multiple data (SIMD) units. Examples of CPUs utilizingmultiple processor cores include the PowerPC® line of CPUs, availablefrom International Business Machines (IBM) of Armonk, N.Y.

As illustrated, each processor core 112 may have access to its ownprimary (L1) cache 114, as well as a larger shared secondary (L2) cache116. In general, copies of data utilized by the processor cores 112 maybe stored locally in the L2 cache 116, preventing or reducing the numberof relatively slower accesses to external main memory 140. Similarly,data utilized often by a processor core 112 may be stored in its L1cache 114, preventing or reducing the number of relatively sloweraccesses to the L2 cache 116.

The CPU 110 may communicate with external devices, such as a graphicsprocessing unit (GPU) 130 and/or a memory controller 136 via a system orfrontside bus (FSB) 128. The CPU 110 may include an FSB interface 120 topass data between the external devices and the processing cores 112(through the L2 cache) via the FSB 128. An FSB interface 132 on the GPU130 may have similar components as the FSB interface 120, configured toexchange data with one or more graphics processors 134, input output(I/O) unit 138, and the memory controller 136 (illustratively shown asintegrated with the GPU 130).

The FSB interface 120 may include any suitable components, such as aphysical layer (not shown) for implementing the hardware protocolnecessary for receiving and sending data over the FSB 128. Such aphysical layer may exchange data with an intermediate “link” layer whichmay format data received from or to be sent to a transaction layer. Thetransaction layer may exchange data with the processor cores 112 via acore bus interface (CBI) 118.

Secure Data Processing

As part of an enhanced security feature, the CPU 110 may encrypt someportions of data, referred to herein as secure data, prior to storing itin main memory 140 (such encrypted portions of data are illustrativelyshown as secure data 142 in main memory 140). Accordingly, the CPU 110may include a security component 150 used to encrypt secure data priorto transmission over the FSB 128 by the FSB interface 120. Upon laterretrieval of the encrypted data, the security component 150 may also beused to decrypt the encrypted secure data prior to passing it into theL2 cache 116 for use by one or more of the processor cores 112.

The security component 150 may employ any suitable encryption algorithmsor combination of algorithms for encryption/decryption, including, butnot limited to algorithms utilizing whitening keys, hash keys, and/orAdvanced Encryption Standard (AES) keys. For some embodiments, one ormore of these keys may be generated based on a master key 162 stored inpersistent storage 160 located on the CPU 110. For other embodiments,the master key 162 may be used to protect these keys, for example, byencrypting a data structure containing the keys or used to generate thekeys. As will be described in greater detail below, encryption may alsoutilize a security version parameter (version 164) also stored inpersistent storage 160. In some cases, information regarding the key(s),as well as the version 164 used for encryption, and/or validation ofencrypted data, may be encrypted and stored externally, as a secureblock of data, shown as security metadata 144. As will be described ingreater detail below, upon retrieval of secure data 141, this metadata144 may be retrieved for validation and/or decryption purposes.

As shown in the Figures described below, for some embodiments, theversion 164 may actually be used to encrypt data (e.g., as an input toan encryption algorithm implemented in hardware or software). However,for other embodiments, the version 164 may be used to generate anintegrity check value (a checksum or hash value) on a block of encrypteddata. In either case, the encrypted data may be validated against acurrent version. For example, if the data was encrypted using adifferent version, the decrypted data would not validate. Similarly, anintegrity check value for the encrypted data were generated with adifferent version would not match an integrity check value generatedwith the current version.

FIG. 2A is a block diagram that illustrates the flow of both secure andnon-secure data through the CPU, in accordance with one embodiment ofthe present invention, for example, as data is read into the cache frommain memory and written out from the cache to main memory. Such dataflow may take place, for example, when loading instructions and/or dataof a program, such as a game program, into the CPU 110 for execution.While not shown, flow control logic configured to identify and routesecure and non-secure data in accordance with FIG. 2A may be included inthe FSB interface 120.

Note that data received from cache will typically be unencrypted(plaintext) regardless of whether the data is secure or non-secure. Ifthe data is not secure, the plaintext data is written directly out toexternal memory. Any suitable technique may be utilized to determine ifthe data is secure. As an example, a specific address range may bereserved for secure data. As another example, secure data may beidentified by one or more bit settings in a page table entry, forexample, indicating a corresponding cache line is secure. In any case,if the data is secure, the plaintext data is routed to an encryptionengine 152 of the security component 150 for encryption. The encryptionengine 152 encrypts the secure data and returns the secure dataencrypted (as ciphertext). For some embodiments, an integrity checkvalue (ICV) may be calculated based on the secure data in plaintextand/or ciphertext form, to allow for subsequent authentication to ensurethe encrypted data was not modified (tampered with). Depending on theembodiment, this integrity check value may also be stored externally, asmetadata 144, or internally.

As illustrated in FIG. 2B, the encryption engine 152 may encrypt theplaintext data using the master key 162 (and/or other keys) and version164 stored in persistent storage 160. Accordingly, a change in version164 results in different encryption (e.g., different ciphertext giventhe same plaintext), thus providing a convenient mechanism to vary theencryption. As illustrated, the decryption engine 154 may also use themaster key 162 (and/or other keys) and version 164 to decrypt ciphertextdata retrieved from external memory. As will be described in greaterdetail below, for some embodiments, in an effort to ensure a securetransition to a dynamically updated security version, the encryptionengine may perform encryption and decryption using the updated securityversion (shown as VERSION +1), prior to actually storing the updatedsecurity version in persistent storage 160. Select logic 155 may allowthe encryption and decryption engines to select the proper version.

As illustrated, data retrieved from external memory that is not secureis forwarded on to the cache, as no decryption is required. If the datais secure, however, the data is ciphertext and, therefore, is routed toa decryption engine 154 of the security component 150 for decryption. Insome cases, information regarding the keys and version data used forencryption (metadata 144) may also be retrieved with the secure data. Aswill be described in further detail below, for some embodiments, avalidation component 170 may be configured to compare the version dataretrieved with the current version 164 in persistent storage 160 toensure the current system is authorized to access the secure data.

While some embodiments may use encryption/decryption engines implementedin hardware, for some embodiments some or all of the encryption and/orvalidation operations described herein and shown in the Figures may beperformed in software (e.g., running in a secure environment). In suchembodiments, software may have direct access (via the CPU) to the masterkey and/or version information stored in persistent storage, instead ofor in addition to the hardware security component. Accordingly, theconcepts described herein related to storing version information inpersistent storage may be used to advantage in systems utilizinghardware encryption, software encryption, or any combination thereof.

Storing Version Information in Persistent Storage

In any case, the current version 164 in persistent storage 160 of thesystem may be updated periodically, for example, to reflect a user'scurrent set of security privileges that may determine what secure datathat user is authorized to access. In order to accommodate thesechanges, the persistent storage 160 should be some type of storage thatallows writing. For some embodiments, however, to prevent inadvertent orunauthorized rollback of versions used for encryption, the persistentstorage 160 should be such that, once storage elements thereof areprogrammed, they may not be subsequently modified. In other words, thepersistent storage 160 may be configured to provide monotonic updates inone direction with time, such as a version value that may only beincreased.

One example, of a suitable type of storage is electrically programmablefuses, commonly referred to as e-Fuses. As illustrated in FIG. 3A, forsome embodiments, a first set of e-Fuses 302 ₁ . . . 302 _(N) may beused to store master key information, while a second set of e-Fuses 304₁ . . . 304 _(M) may be used to store version information. Asillustrated, fuse control logic 310 may be included In such embodiments,to blow the e-Fuses 302-304 by applying a high blow voltage (V_(BLOW))to fuses, as indicated by e-Fuse programming data (which may be a simplebit string indicating which fuses are to be blown). The fuse controllogic 310 may also be used to readout the state of the fuses 302-304which may subsequently be latched into registers accessible by thesecurity component 150.

For some embodiments, in order to update the version, the next availablee-Fuse 304 may be blown. Accordingly, arbitrarily assuming fuses areblown from left to right, the rightmost fuse may be indicative of thecurrent version. For many applications, it may not be critical that thenext e-Fuse 304 in sequence be blown, but may be sufficient that theversion is changed to a new value (which will result in differentencryption). In such embodiments, the fuse control logic 310 may beconfigured to monitor the state of any e-Fuse 304 being blown and, ifthe e-Fuse 304 does not blow (e.g., within a given period of time), thenext fuse may be blown instead. While this may have the effect ofskipping some versions (e.g., if fuse 304 ₁₀₀ will not blow but 304 ₁₀₁will, “version 100” may be skipped).

For some embodiments, version and master key information may be storedin different types of persistent storage. For example, for someembodiments, the master key information might not be changed during thelife of the product, master key information may be stored in laser fuses322 ₁-322 _(N) rather than e-Fuses, as illustrated in FIG. 3B,. Thelaser fuses 322 ₁-322 _(N) may be blown during a manufacturing process,while the device containing them is still in wafer form, which may beconvenient for system (e.g., game box, PC, etc.) manufacturers. As aresult, however, the device (e.g., CPU) manufactures would have to beprovided with the master key data which may create opportunities for themaster key values to be mishandled, which may compromise security.Therefore, for highly sensitive applications, one advantage to storingthe master key in e-fuses (or some other type of electrically writablepersistent storage) is that system manufactures incorporating thedevices in their products may be able to set the master keys themselves.

Other types of suitable persistent storage may include electricallyerasable programmable read-only memory (EEPROM) or flash memory. Forsome embodiments, systems utilizing EEPROM or flash memories may includecontrol circuitry to ensure that previously written storage elements(memory cells) cannot be modified, while still allowing subsequentstorage elements to be programmed. For example, such control circuitrymay be configured to permanently disable writing to all addresses belowan address currently being written.

Initializing Version and Master Key Information

FIG. 4 is a flow diagram of exemplary operations for initializing masterkey and version data, according to one embodiment of the presentinvention. For illustrative purposes, the operations 400 assume that themaster key information is stored in some type of persistent storage thatis writable at run time.

The operations 400 begin, at step 402, by booting the system. Asdescribed in the commonly assigned, co-pending U.S. application Ser. No.10/691,924 entitled “Initializing, Maintaining, Updating and RecoveringSecure Operation within an Integrated System Employing a Data AccessControl Function,” Filed on Oct. 23, 2003, hereby incorporated herein byreference in its entirety, the first time the system is booted, it maydo so in a non-secure mode. In preparation of entering a secure mode, atstep 404, a master key is generated, for example, based on a hardwarerandom number generator (not shown). At step 406, the master key isstored in persistent storage.

At step 408, an initial security version is obtained. For someembodiments, the initial security version may simply be the initialstate of the persistent storage, such as the initial (e.g., un-blown orpartially blown) state of eFuses. For other embodiments, the initialsecurity may be predetermined, for example, to reflect a current versionof a product. In such cases, the predetermined security version may bestored in persistent storage, at step 410.

With the master key and version in place, the device may enter a securemode, whereby secure data is encrypted using the master key and currentversion. For example, the master key and security version may be used toencrypt data structures to be stored in external memory, such as a datastructure containing security key sets. As previously described, thesecurity version may be stored and encrypted with the data, to allowlater comparison against the current security version when retrievingthe encrypted data structure. Accordingly, at step 412, the initialsecurity version is put in a data structure to be encrypted and, at step414, the data structure is encrypted using the initial security versionand master key information. At step 416, the encrypted data structure isstored in external (e.g., FLASH) memory.

At step 418, at least one additional copy of the encrypted datastructure is stored in external memory. For some embodiments,maintaining more than one copy of the encrypted data structure mayensure at least one good copy of the encrypted data is available even ifone or more other copies become invalid for some reason, such astampering or some type of writing error, which may allow data to berecovered in the occurrence of some such event. Maintaining multiplecopies may also allow recovery in the event that updates to theencrypted data structure (e.g., to grant/revoke privileges as describedbelow), which may involve relatively lengthy operations, are interruptedfor any reason, such as an unexpected loss of power. For example, bymaintaining multiple copies, even if one copy becomes corrupted, if theother copy is good it may be used to restore the corrupted copy.

Utilizing Version Information for Secure Validation at Runtime

FIG. 5 is a flow diagram of exemplary operations 500 for secure runtimeoperations utilizing version information, according to one embodiment ofthe present invention. The operations 500 assume that multiple copies(illustratively, two) of an encrypted secure data structure have beenstored in external memory, for example, as shown in the operations 400described above. Further, for illustrative purposes, the operations 500are assumed to be performed in a game system. However, one skilled inthe art will recognize that similar operations may be performed toprovide secure operations in a wide variety of different type systems.

The operations 500 begin, at step 502, by retrieving a first copy of theencrypted data structure and validating the secure data structure usinga current security version. As previously described, the validation mayinvolve generating an integrity check value for the retrieved datastructure using the current security version or decrypting the retrieveddata structure using the current security version. In any case, if thefirst copy of the data structure is valid, as determined at step 504,the second copy of the data structure is retrieved and validated, atstep 512. If the second copy of the data structure is also valid, asdetermined at step 514, redundancy is maintained and an operations modeis entered, at step 522.

If either of the copies of the data structure are not valid, recoveryprocedures may be attempted in an effort to maintain redundancy. Forexample, if the first copy is not valid, a recovery procedure may beattempted, at step 508, wherein the first copy is overwritten with thesecond copy, after which the operations may return to step 502, todetermine if the recovery procedure was successful in restoring thefirst copy. Alternatively, if the second copy is not valid, a recoveryprocedure may be attempted, at step 518, wherein the second copy isoverwritten with the first copy, after which the operations may returnto step 512 to determine if the recovery procedure was successful inrestoring the second copy. For some embodiments, because invalid copiesmay be the result of unrecoverable problems (e.g., irreparable portionsof external memory) there may be a maximum allowable number of retriesthat, if exceeded (as determined at steps 506 and 516), may result infailures (steps 510 and 520), for example, not allowing the system toenter into an operational mode.

Assuming the operational mode is reached, at step 522, a loop ofoperations (524-536) is entered, in which one of two basic operations isperformed: a game is played or privileges are updated. If a game is tobe played, as determined at step 524, the game is loaded using currentsecurity and privilege settings, at step 526. Once the game is over, asdetermined at step 528, the loop of operations is entered again.

In some cases, a user may choose to update privileges, for example, togain some new type of desired functionality. For example, a user mayinitially receive a first set of privileges when purchasing a gamesystem. This first set of privileges may authorize the user to play afirst set of games supplied with the system. The privileges may bestored (in external memory) in the data structure encrypted using asecurity version setting that shipped with the game system. To play anyadditional games may require additional privileges, which may berequested by a user, for example, via an online purchase.

If privileges are to be updated, as determined at step 530, an updateprocedure to securely modify the privilege information and securityversion is performed, at step 532. If the update procedure issuccessful, the user's account is charged, at step 536 and the system isrebooted, at step 540, to reflect the update privilege information. Onthe other hand, if the update procedure is not successful, the user'saccount is not charged, at step 538. However, the system may still berebooted, for example, in an effort restore one of the copies of thesecure data structure which (as will be described in greater detailbelow) may have been corrupted during the failed update procedure.

Utilizing Version Information for Secure Runtime Operation

FIG. 6 illustrates exemplary operations 600 for an update procedure tomodify the secure data structure (e.g., to reflect a change inprivileges) and update a security version. It should be noted, however,that not all types of privilege updates may require modifying thesecurity version. For example, if certain privileges are not to berevoked, and the user is paying for the updates, privilege informationmay be updated in the secure data structure without modifying thesecurity version used to encrypt the data structure. On the other hand,if some privileges are being revoked, it may be desirable to modify thesecurity version to prevent the user from “rolling back” the system toregain the privileges revoked, for example, by replacing the secure datablock with a previous copy.

The operations 600 begin, at step 602, by receiving a request to updatethe security structure with a new security version. At step 604, a testis performed to determine if both copies of the data structure stored inexternal memory are valid (e.g., by decrypting and/or generating anintegrity check value using the current security version). If bothcopies of the current data structure are not valid, a recovery proceduremay be attempted, at step 608. As previously described, a recoveryprocedure may involve overwriting an invalid copy of the data structurewith a valid copy. The validation operations of step 604 may then berepeated. In some cases, if a maximum number of retries is exceeded, asdetermined at step 606, a failure may be reported, at step 610.

However, if both copies of the current data structure are valid, thedata structure is modified (e.g., to reflect a change in privileges) andthe current security version is incremented, at step 612. At step 614,the new data structure is encrypted (and/or an integrity check value isgenerated) using the new security version. In an effort to alwaysmaintain at least one valid copy of the data structure, only one copy ofthe data structures in external memory may be overwritten until thesecurity version is successfully updated in persistent storage, possiblyallowing recovery in the event of a failure in writing the new datastructure to external memory or in writing the new security informationto persistent storage.

Therefore, at step 616, the first copy of the data structure in externalmemory is overwritten with the new data structure. At step 618, the newdata structure is read back from external memory and validated. If thecopy read back is not valid, indicating a possible write failure, theoperations 616-620 may be repeated, up to a maximum number of retries,after which a failure may be reported, at step 626 (e.g., resulting inthe user not being charged for updates, per step 538 of FIG. 5).

If the data structure read back is valid, the persistent storage ismodified to reflect the incremented security version, for example, byburning one or more fuses, at step 628. In some cases, updates to thepersistent storage may not be successful, for example, due to faultystorage elements (e.g., fuses that will not burn). Accordingly, a testmay be performed to determine if the update to persistent storage issuccessful, for example, by performing a read back of fuses, at step630. If a fuse did not burn successfully, attempts to burn the fuse maybe repeated, up until a maximum number of retries for that fuse. Forsome embodiments, the particular fuse burned may not be matter, forexample if a security version is reflected by a total number of fusesburned. Therefore, provided the fuse limit has not been reached (no morefuses to blow), as determined at step 634, the blow operations may berepeated with a different (e.g., the next) fuse selected, at step 636.If the fuse limit has been reached, a failure may be reported, at step628.

If the fuse burning is successful, the second copy of the data structurein external memory is overwritten with the new data structure, at step640, and secure update procedure is complete. Of course, for someembodiments, the second copy of the data structure may be read back andvalidated. Recall, however (referring back to FIG. 5), that afterupdating the data structure, the system may be rebooted (step 540)causing the first and second copies of the data structure to bevalidated (at steps 502 and 512, respectively).

Conclusion

Storing security versions in persistent, but changeable, storage, suchas electronically programmable fused (e-Fuses), may allow such versioninformation to be stored securely while still providing the flexibilityto change the versions while the system is running. Changing the versioninformation while the system is running may allow privileges to begranted and/or revoked dynamically. For some embodiments, datastructures containing the privilege information may be encrypted andvalidated using security version information.

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof, and the scope thereof isdetermined by the claims that follow.

1. A device for encrypting blocks of data to be stored in memoryexternal to the device, comprising: first persistent storage elementsfor storing a security version parameter; second persistent storageelements for storing master key data; an encryption engine configured toencrypt secure blocks of data to be stored in the external memory,wherein at least one of: the encrypted secure blocks or an integritycheck value generated therefore are affected by the security versionparameter; and a mechanism for modifying the first persistent storageelements to update the security version parameter without modifyingpreviously modified first persistent storage elements.
 2. The device ofclaim 1, wherein the first persistent storage elements compriseelectrically programmable fuses.
 3. The device of claim 1, wherein thesecond persistent storage elements comprise electrically programmablefuses.
 4. The device of claim 1, wherein the second persistent storageelements comprise laser fuses.
 5. The device of claim 1, furthercomprising a validation component configured to: validate that asecurity version parameter used to encrypt a retrieved block of securedata, or generate an integrity check value therefor, is the same as thesecurity version parameter maintained in the first persistent storageelements.
 6. The device of claim 1, wherein the device is a centralprocessing unit.
 7. The device of claim 6, wherein the device is acentral processing unit on a gaming system.
 8. The device of claim 7,wherein the secure data contains key information used to decrypt a gameprogram.